Hey all,   It is Oct 3rd, 2024 - if you have a Data Infrastructure Insights né Cloud Insights tenant, you should now be able to see per volume compression data for Pure FlashSystem volumes - this dropped to the US this morning, and the rest of the world yesterday. We have had this storage  wide for approximately forever, but we are now additionally doing this down to the volume level. Pure does not differentiate between dedupe and compression, and has a blended data reduction ratio, so this number is what  we are using to present these compression values on the volume object.       This is an example of what should now be possible with this drop. Good times.   Matt ... View more

If you are a Cloud Insights user, and would like to see us add Pure FlashBlade collector support, drop me a note at ostiguy at netapp dot com , and we can chat about what we are up to, and how you can get involved ... View more

Hey all,   One of the engineering projects we have been working on is building a E-Series collector for CI that uses E-Series' REST API. This should be easier for us to implement enhancements in the future, but also allow easier troubleshooting for y'all in the field as TLS+HTTP is more easily understood versus the legacy API.   We are going to ship this in a few weeks, but I could patch a CI tenant to expose this new collector option today, if you would like. This will result in a new E-Series REST collector tile option for collector creation.   From a functionality standpoint, the REST collector currently is ~105% of what you are accustomed to with the existing legacy API option - we have added a few minor enhancements like populating the "isEncrypted" boolean value as appropriate, and node utilization % as a performance counter is available.   Questions you may have: How do I get it early? I want to be in with the in-crowd! PM me here, or email ostiguy at netapp dot com, with your CI tenant URI. How do I migrate to it? Ensure you have a CI AU with HTTPS connectivity to the E-Series array. Create a new E-Series REST collector, and once it is successful, you can then remove the legacy collector Will I lose history if I follow the migration plan above? Nope What is required? Monitor/read only level credentials, and HTTPS connectivity to the array from a CI Acquisition Unit hosting the collector. You can populate the IP/hostname field with a comma delimited string - the collector ONLY needs to speak to one controller in the array, but if you populate this field with a comma delimited string, CI should intelligently attempt to speak to the second controller IF for whatever reason the first is inaccessible. Populating this field with only one IP/simple hostname/FQDN is also technically possible, but probably not a best practice for resiliency. Is the off-array installable E-Series REST API deployment supported? No - we are only targeting E-Series arrays with native REST API capabilities. We'd recommend continuing to use the legacy collector for any older arrays lacking native REST API capabilities.   Matt   ... View more

Hey all,   Wherever you are in the world, if you are a Cloud Insights user, you will no longer see the "Preview" label on our Brocade / Broadcom FOS REST collector thanks to deployments earlier this week.  In the past quarter, we have been refining and enhancing our approach, and we think this collector is ready for general usage.    There are a few aspects to consider:    FOS introduced their REST API with FOS 8.2. But some features like routing only received REST API capabilities with 9.0 = if you are a Brocade routing shop, if you are NOT yet on 9, you probably want to wait to switch to REST    If you have a fabric consisting of mixed FOS assets 8.2 higher, but with some < 8.2, your CI FOS REST collector WILL fail to discover those older assets. You can edit your FOS REST collector, and build a comma delimited list of the IPv4 address of those devices for exclusion from that collector = this will stop this collector from reporting "Partial Success...." Your strategy for discovering earlier assets should be our Brocade CLI+SNMP based collector.      We general expect that CI users will find this collector much easier to deploy - the historical Brocade CLI+SNMP collector requires both an appropriate user account AND correct SNMP configuration for both inventory and performance collection success - the FOS REST collector is purely REST API based.   Finally, this collector is also doing something I find pretty cool - to continue the theme of improving usability, we are dynamically attempting to speak to each switch with both HTTP and HTTPS as Brocade FOS devices only want to speak one of those - if your switch has a digital certificate installed, it blocks HTTP data flow via REST. If your switch does not have a digital certificate installed, TCP port 443 has nothing listening, such that inbound requests from CI result in a TCP timeout.   So, this collector has some options to change protocol from HTTPS to HTTP much like many of our collector types, but that simply changes the order in what we attempt first - we will try the other in the first fails before presenting any errors.   So, all things considered, I am very optimistic folks will find our FOS REST collector much easier to deploy and maintain.   Matt ... View more